Skip to main content

Agent 编排范式

前置:会调大模型 API。不需要用过任何 Agent 框架。

本专题回答:ReAct、Plan-and-Execute、Supervisor 这些名字分别指什么做法,我手上这个需求该用哪个。

一、这些名字回答的是同一个问题

你已经会调大模型 API 了。现在要做一个真正干活的系统 —— 会查资料、会改代码、会写报告的那种。

于是你面对一堆词:ReAct、Plan-and-Execute、多智能体、Deep Research、Reflection……

第一次见到,很容易以为这是六种不同的技术。其实它们是同一个问题的六种答案,那个问题是:这一步做完了,下一步做什么,由谁来决定?

  • 你的代码决定 → Workflow
  • 模型一步步决定 → ReAct
  • 模型先规划、再照计划走 → Plan-and-Execute
  • 评审员决定要不要重来 → Reflection
  • 主管决定派谁去干 → Supervisor
  • 一群代理并行探索再汇总 → Deep Research

这个专题就是把这些答案,一个一个从零讲清楚。

二、和另外两个专题的分工

Agent 应用下现在有三个专题,切的是三个不同的问题:

专题回答的问题拆的东西
Agent 框架横向对比我该用 LangGraph 还是 OpenAI Agents SDK?框架的 API 和能力边界
通用 Agent 产品源码拆解Manus、Kimi CLI 内部怎么调度子 Agent?已上线产品的真实实现
本专题ReAct 和 Plan-and-Execute 差在哪,我该用哪个?范式本身 + 它在库里的标准实现

换个说法:

  • 框架专题告诉你有哪些工具
  • 产品专题告诉你别人怎么用
  • 这个专题告诉你这些做法各自叫什么、原理是什么、什么时候会失效

三、七个范式的位置

把它们按「谁决定下一步」排成一条线,位置就固定了:

主链:按「谁决定下一步」排序02 Workflow代码写死路径模型只填空01 ReAct模型决定一次一步03 Plan-and-Execute先出完整计划再照计划走05 Supervisor主管决定派谁去干06 Deep Research派一批子代理并行探索再综合← 可控、便宜、可预测自主、昂贵、能干难活 →不在主链上,可叠加到任意一环04 Reflection加一个评审回路,不满意就重来挂在任意一环07 代码即行动 CodeAct换掉动作的编码方式替换 01主链上的任意一环
六个范式是叠加关系而非六选一:Deep Research 内部同时用了 Plan、Supervisor 和 Reflection,而每个子代理跑的仍是 ReAct 循环。
← 可控、便宜、可预测        自主、昂贵、能干难活 →

两点要先说明

  1. 它们是叠加的,不是六选一。 Deep Research 内部同时用了 Plan、Supervisor 和 Reflection,而每个子代理跑的还是 ReAct 循环。
  2. Reflection 不在主干上,它是个可以挂在任何范式之上的附加回路。

四、按什么顺序读

如果你是从零开始,按顺序读。 后面的每一篇都建立在前面之上,跳读会卡住。

#篇目讲什么前置你会写出什么
01ReAct大模型怎么用上工具会调 API一个能改你文件的 Agent
02Workflow 编排什么时候不该用 Agent01链式 / 并行 / 路由三种形状
03Plan-and-Execute长任务为什么跑偏,怎么治01一个会自己列 todo 的 Agent
04Reflection做完的东西谁验收01生成-评审回路(含防空转)
05Supervisor 多智能体一个 Agent 装不下的活01、03星型和网状两种多 Agent 结构
06Deep Research带引用的调研报告怎么产出前五篇一个完整的六节点研究系统
07代码即行动
CodeAct / Code Mode
用写代码代替吐 JSON 工具调用01一个动作即代码的 Agent
08横向对比与选型遇到需求怎么选——二维坐标系与五问判据表

如果你已经写过 Agent,可以直接跳到 08 横向对比 看结论,再回头挑感兴趣的篇目。

如果你只想解决一个具体问题

你的困扰直接看
Agent 死循环烧钱01 第六节
明明路径固定,却搞得很复杂很贵02
任务跑一半忘了目标03
加了自我反思但质量没提升04 第六节
上下文老是爆05
报告写得像编的,没法溯源06
工具太多,光定义就撑爆上下文07

五、每篇正文的固定结构

七篇正文都用同一套骨架,方便你横向对比:

建立概念零 开始之前前置知识与本篇目标一 真实问题先看它要解决什么二 朴素办法为什么不够用三 概念是什么配图与类比四 动手搭step by step讲透与落地五 关键决定为什么这样设计六 从玩具到生产工业级实现多了什么七 常见故障按「观察到什么现象」组织八 什么时候别用比「什么时候用」更有价值九 小��结自查清单
红色两节是刻意设计的:故障按「你会观察到什么现象」组织而不是按原因,因为出问题时你手上只有现象;「什么时候别用」放在「什么时候用」之前,因为多数事故来自用错范式而不是用错参数。

其中两节你多半会反复回来查:

  • 「七、常见故障」是按你会观察到的现象组织的,不是按原因组织 —— 因为线上出问题的时候,你手上只有现象。看到「它一直在重复调同一个工具」,直接去那一节找这一行
  • 「八、什么时候别用」通常比「什么时候用」更值钱 —— 大多数事故来自范式选错,而不是参数调错

六、你可能还听过的另外几个名字

搜这个话题的时候,下面这些词也会冒出来。它们没有单独成篇,原因不是不重要,而是各有各的去处:

你可能听过的它的实际处境
GroupChat / 角色扮演流水线AutoGen、MetaGPT 那一派:几个角色你一言我一语把活干了。demo 看着很惊艳,但公开的生产案例极少,多数团队试完退回了 Supervisor
ReWOO / LLM Compiler不是新范式,是 Plan-and-Execute 的两个变体 —— 一个先把整个计划一次列完再执行,一个把能同时做的步骤挑出来并行跑。并进 03
Tree of Thoughts / LATS让模型同时探索好几条思路,走不通就回退。论文指标确实好看,但一道题要跑几十次模型,成本在生产上压不住,目前还是研究向
多智能体辩论让几个模型互相挑错。同上,效果是有的,一次任务的账算不过来
强化学习(RL / RLVR)它根本不在这一层。 编排讲的是「模型已经训好了,运行时怎么安排它干活」;RL 讲的是「回去改模型的权重」。这两件事经常被摆在一起比较,04 第八节 专门澄清了区别

七、本专题引用的材料

拆源码最怕把二手解读当一手事实。下面每份材料都标了协议,正文引用时会注明出处。

来源Star协议用在哪几篇
anthropics/claude-cookbooks51,826MIT02 / 04 / 05 / 06
shareAI-lab/learn-claude-code74,605MIT01 / 03 / 05
datawhalechina/hello-agents73,668CC BY-NC-SA 4.001 / 03 / 04 / 06
langchain-ai/open_deep_research12,636MIT06
langchain-ai/langgraph-supervisor1,643MIT05
langchain-ai/langgraph-swarm1,557MIT05
openai/openai-agents-python28,757MIT05

关于 Hello-Agents 的协议:它是 CC BY-NC-SA 4.0(署名 - 非商业 - 相同方式共享)。本专题的做法是引用其配图(注明出处)+ 引用少量关键段落 + 内容自行重写,不做整章转载。

八、从这里开始

01 · ReAct:从零搭一个会用工具的 Agent

它是另外五个范式的地基,读完你会有一个真能干活的 Agent。